A conventional network file system (NFS) architecture includes an NFS server and one or more NFS clients. The NFS clients may store data and/or metadata in memory and/or in a solid state device (SSD). The NFS server is a central repository for both files and metadata. The metadata may be, for example, information about the files including but not limited to, a file access time, a file owner, a file update time, and file permissions. An NFS client may acquire a file from the NFS server and may store a local copy of the file and its metadata in the NFS client memory. An application may then use the local copy of the file and its metadata instead of having to work across the network on the copy of the file stored at the NFS server. If there was only one NFS client and only one file and only one application working on the file then storing the local copy of the file and the local copy of the metadata might not produce significant issues.
However, an NFS server may interact with many NFS clients that want to store a local copy of a file and its metadata. Then, many applications on an NFS client may want to interact with the local copy of the file and its metadata. With multiple clients storing multiple local copies that are operated on by multiple applications it is easy to imagine how a cache coherency problem could arise where metadata got out-of-date at the NFS server and/or at an NFS client. For example, two applications on two different NFS clients could do two different things to their respective local copies of the file and to its metadata at substantially the same time.
Conventionally, NFS has handled this issue by centralizing file and metadata control, by forcing NFS clients to communicate metadata impacting actions to the NFS server, and by forcing NFS clients to “retire” metadata periodically (e.g., every 30 seconds). After metadata is retired, an NFS client may ask the NFS server for a new copy of the metadata. If there are a small number of NFS clients asking for fresh copies then this retire/refresh protocol may not be too burdensome. However, when the number of NFS clients grows too large, the centralized metadata control procedure and the retire/refresh protocol can cause the NFS server to become a bottleneck. Also, if the file and/or metadata is only being touched by the one NFS client, then the retire/refresh protocol may be unnecessary.
FIG. 1 illustrates a conventional NFS client/server environment. A first application 110 uses an NFS client 112 to communicate with an NFS server 130. Similarly, a second application 120 uses a second, different NFS client 122 to communicate with the NFS server 130. The first application 110 and the first NFS client 112 may run on a first computer while the second application 120 and the second NFS client 122 may run on a second computer. The first application 110 and the first NFS client 112 may interact with local files 118 and local metadata 119 that are stored in memory 114. Similarly, the second application 120 and the second NFS client 122 may interact with local files 128 and local metadata 129 that are stored in memory 124.
In this conventional environment, metadata control is centralized in NFS server 130. Metadata requests flow to and through NFS server 130. There is no peer-to-peer communication between the NFS client 112 and the NFS client 122 concerning metadata. When the number of applications and/or NFS clients grows beyond a certain limit, the NFS server 130 may unnecessarily become a bottleneck.